Many software applications have system environment requirements that must be fulfilled for the application to execute properly. In a scenario in which one application is to be integrated with another application, such as with integration of a database application with a database management system, the database management system environment must meet the integrated application's system environment requirements in order for the application to function properly. If the system requirements are not met, then the application may not install properly or the application may install but behave unpredictably, possibly resulting in system corruption.
To avoid problems with a system environment, application installation developers may write custom libraries to check for, or validate, system environment properties (e.g., system parameters, OS versions, packages, patches, service packs, etc.) in an automated manner. While avoiding problems that may occur by relying on a user manually performing all of the prerequisite system environment checks (“validation checks”) for an application, custom program code may lead to other problems.
For example, validation checks may not be modified, or new checks added, without re-releasing the application and installation modules. Thus, the validation checks that are to be performed in association with a given operation (e.g., an install operation), as well as the reference information on which a validation check relies, are relatively static in nature. Each system property to be validated for a given application has a single fixed value requirement for the application, for checking against the actual system property. For example, a given application may have a requirement for a particular amount of RAM in order to function properly. Additionally, there is no capability for introducing interdependencies between various validation checks.
Furthermore, different sets of validation checks might need to be performed depending on the operation being performed in association with the application. For example, the following may affect the set of checks to perform: (a) whether the operation is being performed on a single stand-alone machine or clustered machines, and (b) whether the operation being performed is an install operation, an upgrade operation, adding languages, etc.
Still further, validation frameworks typically do not scale well and, therefore, fail to adequately support or function well as more and more application products are integrated into a single system, such as when installing interdependent suites of products.
Moreover, it would be beneficial, in some circumstances, if a validation tool were able to repair some or all of the conditions that gave rise to a validation failure.
Each of the foregoing desirable features would provide value that is independent of the other desirable features. Furthermore, the approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.